The infrastructure of the Internet, by and large, is maintained by Internet service providers (ISPs) that cater to regional customers and by Internet backbone providers (IBPs) that serve large organizations and ISPs. Some IBPs have recently branched into content delivery network (CDN) services; separately, other ISPs have started offering on-demand video streaming to compete with pure-play content providers. These developments have intensified the competition in both content delivery and media-streaming markets. For the content delivery market, we study the competition equilibriums by analyzing factors such as market share, cost structure, service pricing, and subscriber preference. Our approach helps identify conditions under which a content provider should choose an IBP over the incumbent CDN for content distribution. We also show how an IBP’s CDN venture affects its interconnection relationship with ISPs. For the streaming service market, we examine conditions under which a content provider would partner with an ISP to lower operating and marketing costs while providing a more streamlined subscriber experience. Analytically, our game-theoretical models can optimize key contracting and pricing strategies for multiple classes of service providers; empirically, insights derived from the proposed models have anticipated events that coincide with several recent developments in content delivery and streaming service markets.
This paper presents a project management policy in which the appearance of software faults during system construction is used to determine the timing of system integration activities (e.g., team meetings, analyzing modules for interface inconsistencies, system fault correction, and so on). System integration is performed only if a threshold fault count has been exceeded; otherwise, module development is allowed to continue. We derive an expression for calculating fault thresholds and analyze the policy to reveal the presence of three operating regions: (1) a region in which development should continue with no system integration, (2) a region in which system integration occurs if a threshold fault count has been exceeded, and (3) a region in which system integration should always take place. Analytical and numerical results demonstrate how the fault thresholds change with system complexity, team skill, development environment, and project schedule. We also show how learning that occurs during each round of system integration leads to less frequent integration in the future, and lower total construction effort. Simulation experiments reveal that the fault threshold policy can be applied even if several homogeneity assumptions in the model are relaxed, allowing for differences in the propensity among modules to accumulate faults and the effort needed to correct these faults. Finally, the fault threshold policy outperforms a fixed-release policy in which system integration occurs whenever a fixed number of modules has been released.